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Abstract. Side channel attacks have emerged as a serious threat to 
the security of both networked and embedded systems - in particular 
through the implementations of cryptographic operations. Side channels 
can be difficult to model formally, but with careful coding and program 
transformation techniques it may be possible to verify security in the 
presence of specific side-channel attacks. But what if a program inten- 
tionally makes a tradeoff between security and efficiency and leaks some 
information through a side channel? In this paper we study such trade- 
offs using ideas from recent research on declassification. We present a 
semantic model of security for programs which allow for declassification 
through side channels, and show how side-channel declassification can 
be verified using off-the-shelf software model checking tools. Finally, to 
make it simpler for verifiers to check that a program conforms to a partic- 
ular side-channel declassification policy we introduce a further tradeoff 
between efficiency and verifiability: by writing programs in a particular 
"manifest form" security becomes considerably easier to verify. 



1 Introduction 

One of the pillars of computer security is confidentiality - keeping secrets secret. 
Much recent research in language based security has focused on how to ensure 
that information flows within programs do not violate the intended confiden- 
tiality properties [SM03] . One of the difficulties of tracking information flows is 
that information may flow in various indirect ways. Over 30 years ago, Lamp- 
son [Lam73] coined the phrase covert channel to describe channels which were 
not intended for information transmission at all. At that time the concern was 
unintended transmission of information between users on timeshared mainframe 
computers. In much security research that followed, it was not considered worth 
the effort to consider covert channels. But with the increased exposure of sensi- 
tive information to potential attackers, and the ubiquitous use of cryptographic 
mechanisms, covert channels have emerged as a serious threat to the security 
of modern systems - both networked and embedded. The following key papers 
provide a view of the modern side-channel threat landscape: 



• Kocher [Koc96] showed that by taking timing measurements of RSA cryp- 
tographic operations one could discover secret keys. Later [KJJ99] it was 
shown that one could do the same by measuring power consumption. 

• Based on Koclicr's ideas numerous smart card implementations of crypto- 
graphic operations have shown to be breakable. See e.g. [MDS99]. 

• Brumley and Bonch [BB05] showed that timing attacks were not just relevant 
to smart cards and other physical cryptographic tokens, but could be effective 
across a network; they developed a remote timing attack on an SSL library 
commonly used in web servers. 

What is striking about these methods is that the attacks are on the imple- 
mentations and not features of the basic intended functionality. Mathematically, 
cryptographic methods are adequately secure, but useless if the functionally cor- 
rect implementation has timing or other side channels. 



1.1 Simple Timing Channels 

Timing leaks often arise from the fact that computation involves branching on 
the value of a secret. Different instructions are executed in each branch, and 
these give rise to a timing leak or a power leak (whereby a simple power analysis 
[MSOO] can reveal information about e.g. control flow paths). 

One approach is to ensure that both branches take the same time [AgaOO], 
or to eliminate branches altogether [MPSW05] - an approach that is also well 
known from real-time systems where it is used to make worst case execution 
time easy to determine [PB02]. 

Consider the pseudocode in Figure 1 representing 

r = 1 * 

' a naive implementation of modular exponentiation, 

' , , which we will use as our running example through- 
while (i >= 0) { , & y & 

out the paper. 

x" = r * r * 

■ f (d['] -- 1) data that goes in to this function is typically 

secret. A common scenario is that the variable x is 
part of a secret which is to be encrypted or decrypted 
' and variable d is the key (viewed here as an array of 

bits). It is important that these remain secret. (On 
' the other hand, m, the length of the key, is usually 

considered pubHc knowledge.) 

'_ However, as this function is currently written it 

is possible to derive some or all of the information 
Fig. 1. Modular expo- about the key using either a timing or power attack, 
nentiation The length of the loop will always reveal the size of 

the key - and this is accepted. In the body of the loop 
there is a conditional statement which is executed depending on whether the 
current bit in the key is set or not. This means that each iteration of the loop 
will take different amount of time depending on the value of the key. A timing 
attack measuring the time it takes to compute the whole result can be used to 
learn the hamming weight of the key, i.e. the number of I's. With control over 



the key and repeated runs this is sufficient to leak the key [Koc96]. A power 
analysis could in principle even leak the key in a single run. 



1.2 Timing and Declassification 

Often the run-time cost of securing an algorithm against timing attacks using a 
general purpose method is higher than what we are prepared to pay. 

7^7 ~ ^ ~ For example, using a table-lookup instead of a 

[1] - * *M mod N branch [Cor99] the conditional can be replaced 
_ |. ^ |. . ^ ^ by the code to the left. This fixes the timing leak, 

but the algorithm becomes considerably slower 

- even after eliminating the common subexpres- 
sion. Another even more costly approach is Agat's cross copying idea, whereby 
(roughly speaking) every branch on a secret value if h then A else B is trans- 
formed into if h then A ; [B] else [A] ; B where [A] is a ghost copy of A which 
takes the same time to compute but otherwise has no effect. There are opti- 
misations of this approach using unification [KM06] , or by making the padding 
probabilistic [DHW08], but efficiency wise the improvements offered by those 
techniques are probably not sufhcient in this context. 

A potential solution to this tension be- 
tween security and efficiency is to make a 
tradeoff between the two. For this reason it 
is not uncommon for algorithms to have some 
side channel leakage. An example of this is 
the following variation on modular exponen- 
tiation, adapted from [CMCJ04], which is in- 
tended to provide some (unspecified) degree 
of protection against simple power analysis at- 
tacks (but still leaks the hamming weight of 
Fig. 2. Protected exponentiation the key). 
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Research Goals and Approach Our research goal is to determine how to express 
this tradeoff. There are three key issues to explore: 

• Security Policies: how should we specify side-channel declassification? 

• Security Mechanisms: how to derive programs which achieve the tradeoff? 

• Security Assurance: how can we show that programs satisfy a given policy, 
with a rigorous specification and formal verification? 

This paper deals primarily with the first and the third point. 

The first step - a prerequisite to a rigorous specification - is to specify our 
attacker model. A model sets the boundaries of our investigation (and as always 
with covert channels, there are certainly attacks which fall outside). We choose 
(as discussed in Section 3) the program counter security model [MPSW05]. This 
model captures attackers performing simple power and timing analysis. 



To specify a security policy we turn to work on declassification. The concept 
of declassification has been developed specifically to allow the programmer to 
specify what, where, or when a piece of information is allowed to leak (and by 
whom). A simple example is a program which requires a password based login. 
For this program to work it must declassify (intentionally leak) the value of the 
comparison between the actual and the user supplied password strings. 

Declassification has been a recent hot topic in information flow security (see 
[SS05] for an overview). The standard techniques for declassification seem largely 
applicable to our problem, but there are some differences. The reason being that 
(in the context of cryptographic algorithms in particular) we may be interested 
in the distinction between declassifying some data directly (something which 
has potentially zero cost to the attacker), and declassifying the data but only 
through a side channel - the latter is what we call side channel declassification. 

We will adapt existing declassification concepts to specify what information 
we are willing to leak through timing channels (Section 4) . More specifically, we 
use small programs as a specification of what information is leaked. This follows 
the style of delimited release [SM04]. As an example, we might want to specify 
that a program does not leak more that the hamming weight of the key. This 
can be achieved by using the program fragment in Figure 3 as a specification: it 
explicitly computes the hamming weight of the key. 

The formal definition of side-channel de- 
' classification (Section 4) is that if the attacker 

■""l^.l"^ ^, ^_ ^ knows the information leaked by the declassi- 

1) { ^^''^ then nothing more is learned by running 

^ _ ^ _^ _^ the program. 

y ' We then turn to the question of verifica- 

, tion. We investigate the use of off-shelf auto- 

1=1—1' 

y ' matic program verification tools to verify side- 

channel declassification policies. The first step 

is to reify the side channel by transforming the 
Fig. 3. Hamming weight com- program to represent the side-channel as part 
putation of the program state (Section 5). This reduces 

the specification of side-channel declassifica- 
tion to an extcnsional program property. 

The next step is to observe that in many common cases we can simplify the 
side-channel instrumentation. This simplification (described in Section 5.1) does 
not need to be semantics preserving - it simply needs to preserve the side-channel 
declassification condition. 

As we aim to use automatic off-the-shelf model checkers we need one final 
transformation to make our programs amenable to verification. We use self com- 
position to reduce the verification problem to a safety property of a transformed 
program. Section 6 describes the approach and experiments with software model 
checkers. 

For various reasons the side-channel declassification property of algorithms 
can still be hard to verify. The last part of this work (Section 7) introduces a 



tradeoff which makes verification much simpler. The idea is to write programs 
in what we call manifest form. In manifest form the program is written in two 
parts: a declassifier first computes what is to be released, and then using this 
information a side-channel secure program computes the rest. 

The verification problem amounts to showing that the second part of the 
program is indeed side-channel secure (this can be rather straightforward due 
to the strength of the side-channel security condition), and that the declassifier 
satisfies the property that it docs not leak more through its side channel than it 
leaks directly. We call these manifest declassifiers. Since declassifiers arc much 
simpler (and quite likely useful in many different algorithmic contexts) verifica- 
tion of manifest declassifiers is relatively simple. We show how this technique 
can overcome the verification limitations of certain verification tools. 

An extended version of this article containing material left out for reasons of 
space constraints is available as technical report no. 2009:13 from Department 
of Computing Science and Engineering at and from arxiv.org/. . .. www.cse. 
Chalmers . se/~josef s. 

2 Preliminaries 

In this section we present the language we are going to use and set up the basic 
machinery in order to define our notion of security. 

Since we target cryptographic algorithms we will be using a small while 
language with arrays. It's syntax is defined below: 

C G Command ::= x = e \ x[y] = e | Ci; C2 | if e then Ci else C2 | while e C | skip 
e G Expression ::= x \ x[e] \ n \ ei op 62 \ x 7 y : z 
op € Operators := + | * | — | ~ | mod | . . . 

The commands of the program should not require much explanation as they 
are standard for a small while language. 

One particular form of expression that we have chosen to include that may 
not look very standard (for a toy language) is the ternary operator borrowed 
from the language C. It's a conditional expression that can choose between the 
value of two different register based on the value of a third register. We have 
restricted it to only operate on registers since allowing it to choose between 
evaluating two general expressions may give rise to side channels. This kind of 
operation can typically be implemented to take a constant amount of time so 
that it doesn't exhibit a side channel by using conditional assignment that is 
available in e.g. x86 machine code. 

The semantics of programs is completely standard. We defer the definition 
until the next section where an operational semantics is given together with some 
additional instrumentation. 

3 Baseline Security Model 

In this section we present the semantic security model which we use to model the 
attacker and to define the baseline notion of declassification-free security. For a 



good balance between simplicity and strength we adopt an existing approach: 
the program counter security model [MPSW05]. This attacker model is strong 
enough to analyze simple power analysis attacks [KJJ99] - where the attacker 
is assumed to be able to make detailed correlations between the power profile of 
a single run with the instructions executed during that run. 

The idea of the program counter security model is to assume the attacker can 
observe a transcript consisting of the sequence of program counter positions. This 
is slightly stronger than an attacker who could perfectly deduce the sequence 
of instructions executed from a (known) program given a power consumption 
profile of an execution. It docs, however, assume that the power consumption of 
a particular operation docs not depend on the data it manipulates. In particular 
it docs not model differential power analysis. 

Suppose a program operates on a state which can be partitioned into a low 
(public) part, and a high (secret) part. A program is said to be Transcript-secure 
if given any two states whose low parts are equal, running the program on these 
respective states yields equal transcripts and final states which also agree on 
their low parts. ^ 

To specialise this definition to our language we note that it is sufficient for the 
attacker to observe the sequence of branch decisions in a given run in order to be 
able to deduce the sequence of instructions that were executed. To this end, in 
Figure 3 we give an instrumented semantics for our language which makes this 
model of side channels concrete. Apart from the instrumentation (in the form 
of labels on the transitions) this is a completely standard small-step operational 
semantics. The transition labels, o, are either a silent step (r), a or a 1. A zero 
or one is used to record which branch was taken in an if or while statement. 

Definition 1 (Transcript). Let c?i, ^2, • ■ • range over {0, 1}. We say that a con- 
figuration (C, S) has a transcript c?i, . . . , d„ if there exist configurations (Ci, Si) , 
i £ [1, JT-] such that 

(C, S)^* ^ (Ci, S-i) A* *i . . . ^* ^ (C„, Sn) ^* (skip, 5") 
for some S' . 

In the above case we will write ICJS* = S" (when we only care about the final 
state) and [CJ S — {S',t) where t ~ di, . . . ,dn (when we are interested in the 
state and the transcript). 

For the purpose of this paper (and the kinds of algorithms in which we are inter- 
ested in this context) we will implicitly treat [C] and [[CJ as functions rather 
than partial functions, thus ignoring programs which do not always terminate. 

Now we can formally define the baseline security definition, which following 
[MPSW05] we call Transcript-security: 

^ It would be natural to assume that attackers have only polynomially bounded com- 
puting power in the size of the high part of the state. For the purposes of this paper 
our stronger definition will suffice. 



{x[e],S) i^S{x)iv) 

{ei,S}ii.vi {e2,S}ii.V2 S{x)^0 S{x) = 



{eiope2,5> Jli'iopi-a {x?y: z, S) S{y) {x?y: z, S) ij. Siz) 



{x = e,S) ^ (skip, S[x ^ v]) {x[y] = e,S)^ (skip, S[x ^ x[S{y) ^ v]]) 

/ 1 • ^ c\ ^ //^ c\ {Ci,S) A {C'i,S') 

(skip; C, S) ^ (C, S) — , — 

(Ci; C2, S) ^ (Ci; C2, 5 ) 

(e, S)ii,v v^O (e, 5") 4 



(if e Ci C2, 5") -i* (Ci, 5") (if e Ci C2, S) (C2, S} 



(while e C, S) ^ (C; while e C, S) (while eC,S)^ (skip, 5) 



Fig. 4. Instrumented Semantics 

Definition 2 (Transcript-Security). Assume a partition of program variables 
into low and high. M^e wrife R ~l S if program states R and S differ on at 
most their high variables. We extend this to state-transcript pairs by {R,ti) =l 
(5, t2) <==^ R ~L S & ti — t2 reflecting the fact that a transcript is considered 
attacker observable (low). 

A program C is Transcript-secure if for all R, S, ifR^L S then [[Cf R =l 

icfs. 

Note that Transcript-security, as we have defined it, is a very strong condi- 
tion and also very simple to check. A sufficient condition for Transcript-security 
is that the program in question (i) does not assign values computed using high 
variables to low variables, and (ii) does not contain any loops or branches on 
expressions containing high variables. The main contribution of [MPSW05] is a 
suite of methods for transforming programs into this form. Unfortunately the 
transformation can be too costly in general, but that method is nicely comple- 
mented by use of declassification. 



4 Side Channel Declassification 

To weaken the baseline definition of security we adopt one of the simplest mecha- 
nisms to specify what information may be leaked about a secret: delimited release 
[SM04] . The original definition of delimited release specified declassification by 
placing declassify labels on various expressions occurring in a program. The idea 
is that the attacker is permitted to learn about (at most) the values of those 
expressions in the initial state, but nothing more about the high part of the 
state. 



We will reinterpret delimited release using a simple program rather than a 
set of expressions. The idea will be to specify a (hopefully small and simple) 
program D which leaks information from high variables to low ones. A program 
is Transcript-secure modulo declassificr D if it leaks no more than D, and this 
leak occurs through the side channel. 

Definition 3 (Side Channel Declassification). Let D be a program which 
writes to variables distinct from all variables occurring in C . We define C to be 
Transcript-secure modulo D if for all R and S such that R —l S we have 

ICIR IC\S k {mR = mS ^ ICfR =L ICfS). 

The condition on the variables written by D is purely for convenience, but is 
without loss of generality. The first clause of the definition says that the only 
information leak can be through the side channel. The second clause says that 
the leak is no more than what is directly leaked by D. It is perhaps helpful to 
consider this clause in contrapositive form: |C]]"^i? [[C]]"'"S' ^ [[^]^ 7^ I-DlS*. 
This means that if there is an observable difference in the transcripts of two runs 
then that difference is manifest in the corresponding runs of the declassifier. Note 
that if we had omitted the condition \p\R =l JC'JS' then we would have the 
weaker property that C would be allowed to leak either through the store or 
through the side channel - but we wouldn't know which. From an attackers 
point of view it might take quite a bit more effort to attack a program if it only 
leaks though the side channel so it seems useful to make this distinction. Clearly 
there are other variations possible involving multiple declassifiers each leaking 
through a particular subset of observation channels. 

5 Reifying the side channel 

In the previous sections we have a definition of security that enables us to for- 
mally establish the security of programs with respect to side channel declassifi- 
cation. We now turn to the problem of verifying that particular programs fulfil 
the security condition. In order to avoid having to develop our own verification 
method we have chosen to use off-the-shelf software verification tools. 

Software verification tools work with the standard semantics of programs. 
But recall that our security condition uses an instrumented semantics which 
involves a simple abstraction of side channels. In order to make it possible to use 
off-the-shelf tools for our security condition we must reify the transcript so that 
it becomes an explicit value in the program which the tools can reason about. It 
is easy to see how to do this: we add a list-valued variable t to the program, and 
transform, inductively, each conditional if e then C else C into if e then 
t = t++"l"; C else t = t++"0"; C and each while loop while e do C into 

(while e do t = t++"l"; C) ; t= t++"0" 

and inductively transform the subexpressions C and C ' . 



5.1 Simplifying the instrumentation 



Reifying the transcript from the instrumented semantics in this way will create 
a dynamic data structure (a list) which is not bounded in size in general. Such 
data structures make programs more difficult to reason about, especially if we 
want some form of automation in the verification process. Luckily, there are 
several circumstances which help us side step this problem. Concretely we use 
two facts to simplify the reification of the side channel. 

The first simplification we use depends on the fact that we do not have 
to preserve the transcript itself - it is sufficient that it yields the same low- 
equivalence on programs. Suppose that P"^ is the reified variant of the program 
P and that the reification is through the addition of some low variables. In order 
to use for verification of side-channel security properties it is sufficient for it 
to satisfy the following property: 

yR,S.lPfR =L iPfS ^ iP^jR =L IP^P 

We call such a P^ an adequate reification of P. 

The second simplification that we can per- 
form in the construction of a reified pro- 
gram is that we are specifically targeting cryp- 
tographic algorithms. A common structure 
among the ones we have tried to verify is that 
the while loops contain straight line code (but 
potentially conditional expressions). If it is the 
case that while loops don't contain any nested 
branching or looping constructs then we can 
avoid introducing a dynamic data structure to 
model the transcript. Let us refer to such pro- 
grams as unnested. For unnested programs it Fig. 5. Instrumented modular ex- 
is simply enough to use one fresh low variable ponentiation 
for each occurrence of a branch or loop. Thus the reification transformation for 
unnested programs is defined by applying the two transformation rules below to 
each of the loops and branches respectively: 

while e C V = 0; while e (v = v + 1; C) {v fresh) 

if e then C else C ' ^ if e then v = 1 ; C else v = ; C ' {v fresh) 

The program in Figure 5 is an instrumented version of the program in Fig- 
ure 2. The only change is the new (low) variable t which keeps track of the 
number of iterations in the while loop. 
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6 Self Composition 



Standard automatic software model checking tools cannot reason about multiple 
runs of a program. They deal exclusively with safety properties which involves 



reasoning about a single run. As is well-known, noninterference properties (like 
side-channel declassification) are not safety properties - they are defined as prop- 
erties of pairs of computations rather than individual ones. However, a recent 
technique has emerged to reduce noninterference properties to safety properties 
for the purpose of verification. The idea appeared in [DHS03], and was explored 
extensively in [BDR04] where the idea was dubbed self composition. Suppose C 
is the program for which we want to verify noninterference. Let be a bijective 
renaming function to a disjoint set of variables from those used in C. Let Cq de- 
note a variable renamed copy of C. Then the standard noninterference property 
of C can be expressed as a safety property of C;Cg viz. the Hoare triple 

{yv G Low.v ~ 6{v)}C; CgjVv G Low.v = 9v} 

To extend this to deal with side-channel declassification, let us suppose that 
is an adequate reification of C. Then we can verify Transcript-security modulo 
D by the Hoare triple above (non side-channel security) in conjunction with: 

{Vt; e Low.v ^ 6{v)}D; Dg; C^; Cj{(Vx G W.x ^ 0{x)) Vy G Low.y = e{y)} 

where W denotes the variables written by D. Here we take advantage of the 
assumption that the variables written by D are disjoint from those used in C"^. 
This enables us to get away with a single renaming. Note that since D is a, 
program and not an expression we cannot simply use it in the precondition of 
the Hoare triple (c.f. [BDR04,TA05]). 

6.1 Experiments using Self Composition 

As Terauchi and Aiken discovered when they used self composition, it often 
resulted in verification problems that were too hard for the model checkers to 
handle [TA05]. As a result of this they developed a series of techniques for 
making the result of self composition easier to verify. The main technique is the 
observation that the low part of the two initial states must be equal and hence 
any computation that depends only on the low part can safely be shared between 
the two copies of the program. This was reported to help verifying a number of 
programs. We employ the same technique in our experiments. 

We have used the model checkers Blast [HJMS03] and Dagger [GR06] and ap- 
plied them to self composed version of the cryptographic algorithms. In partic- 
ular we have tried to verify the instrumented modular exponentiation algorithm 
in Figure 5 secure modulo the hamming weight of the key (Figure 3). We have 
also tried all the algorithms proposed in [CMCJ04] since they all exhibit some 
form of side-channel leak and therefore have to be shown to be secure relative 
that leak. None of the model checkers were powerful enough to automatically 
verify the programs secure. 

The main reason these tools fail seems to be that they do not reason about the 
contents of arrays. Being able to reason about arrays is crucial for our running 
example, as it involves computing the hamming weight of an array. 



Another problem comes from the fact that the programs we wish to prove 
secure may be very different from its declassifier. Relating two different programs 
with each other is a very difficult task and not something that current software 
model checkers are designed to do. 

By helping the model checkers with some manual intervention it is possible 
to verify the programs secure. Blast has a feature which allows the user to supply 
their own invariants. Given the correct invariants it will succeed with the verifi- 
cation. However, these predicates are not checked for correctness and coming up 
with them can be a highly non-trivial task. We have therefore developed another 
method for verification which we will explore in the next section. 



7 Manifest form 



In this section wc introduce a new way to structure programs to make verifica- 
tion considerably easier: Manifest Form. In manifest form the program is written 
in two parts: a declassifier first computes what is to be released, and then using 
this information a Transcript-secure program computes the rest. Manifest form 
represents a tradeoff: writing a program in manifest form may make it less ef- 
ficient. The idea is that the program makes the declassification explicit in its 
structure (this is similar to the specification of relaxed noninterference [LZ05]). 
But for this to be truly explicit declassification the declassifier itself should not 
leak through its side channel - or more precisely, the declassifier should not leak 
more through its side channel than it does directly through the store. 

Definition 4 (Manifest Declassifier). A program D is said to be a Manifest 
Declassifier if for all R and S 



IDfs 



As an example of a non manifest declassifier, consider the program to the left 
below which declassifies whether an array of length m contains all zeros. Here the 
array length m, and i and the declassified value allz, are low. This is not manifest 
because the transcript leaks more than the store: it reveals the position of the 
first nonzero element. A manifest version of this declassifier is shown on the right: 



i=m-l; allz=l; 
while (allz and i >= 0) { 

allz = (d [i] ? : 1) ; 

i = i - 1: 



> 

i = 



i = m- 1; allz = 1; 
whileCl >= 0) i 

allz *= (d [i] ? : 1) ; 

i = i - 1; 

> 



Definition 5 (Manifest Form). A program P is in Manifest Form if P = 
D; Q where D is a manifest declassifier and Q is transcript secure. 



The program in Figure 6 is written in manifest form but otherwise it rep- 
resents the same algorithm as the program in Figure 2. The first part of the 



program (lines 1-6) computes the hamming weight of the key, d, and this (us- 
ing low variable hamming) is then used in the second part of the program to 
determine the number of loop iterations. 



i = i + 1; 

y 



hamming = 0; 
i = m - 1 ; 
while(i >= 0) { 



hamming += (d[i] ? 1 



0) ; 



7 r = 1; k = 0; 

8 i = m - 1 ; 

9 j = m - 1 + hamming ; 

10 whileCj >= 0) { 

11 r = r*(k?x:r 

12 k = kxord[i]; 

13 i = i-(k?0:l 

14 j = j - 1; 

15 } 



r) ; 



1) ; 



Fig. 6. Modular Exponentiation in Manifest Form 



7.1 Manifest Security Theorem 

Armed with the definitions of sound manifest declassifiers we can now state the 
theorem which is the key to the way we verify side-channel declassification. 

Theorem 1. Given a program P = D;Q with D being a sound manifest declas- 
sifier and Q is transcript secure then P is transcript secure modulo D 

This theorem helps us decompose and simplify the work of verifying that a 
program in manifest form is secure. First, showing that Q is transcript secure is 
straightforward as explained in section 3. Verifying that D is a sound manifest 
declassifier, which might seem like a daunting task given the definition, is actually 
something that is within the reach of current automatic tools for model checking. 

We apply the same techniques of reifying the side channel and self compo- 
sition to the problem of verifying sound manifest declassifiers. When doing so 
we have been able to verify that our implementation of the hamming weight 
computation in Figure 3 is indeed a sound manifest declassifier and thereby es- 
tablishing the security of the modular exponentiation algorithm in Figure 6. We 
have had the same success^ with all the algorithms presented in [CMC J04] . 



The literature on programming language techniques for information flow secu- 
rity is extensive. Sabelfeld and Myers survey [SM03] although some seven years 
old remains the standard reference in the field. It is notable that almost all of 
the work in the area has ignored timing channels. However any automated se- 
curity checking that does not model timing will accept a program which leaks 
information through timing, no matter how blatant the leak is. 



8 Related Work 



^ Using Blast version 2.5 



Agat [AgaOO] showed how a type system for secure information flow could 
be extended to also transform out certain timing leaks by padding the branches 
of appropriate conditionals. Kopf and Mantel give some improvements to Agat's 
approach based on code unification [KM06] . In a related line, Sabelfeld and Sands 
considered timing channels arising from concurrency, and made use of Agat's 
approach [SSOO]. Approximate and probabilistic variants of these ideas have also 
emerged [PHSW07,DHW08]. The problem with padding techniques in general is 
that they do not change the fundamental structure of a leaky algorithm, but use 
the "worst-case principle" [ASOl] to make all computation paths equally slow. 
For cryptographic algorithms this approach is probably not acceptable from a 
performance perspective. 

Hedin and Sands [HS05;Hcd08] consider applying Agat's approach in the 
context of Java bytecodc. One notable contribution is the use of a family of time 
models which can abstract timing behaviour at various levels of accuracy, for 
example to model simple cache behaviour or instructions whose time depends 
on runtime values (e.g. array allocation). The dcflnitions and analysis are param- 
eterised over the time models. The program counter security model [MPSW05] 
can be seen as an instance of this parameterised model. 

More specific to the question of declassification and side channels, as we 
mentioned above, [DHW08] estimates the capacity of a side channel - some- 
thing which can be used to determine whether the leak is acceptable - and 
propose an approximate version of Agat's padding technique. Giacobazzi and 
Mastroeni [GM05] recently extended the abstract noninterference approach to 
characterising what information is leaked to include simple timing channels. 
Their theoretical framework could be used to extend the present work. In par- 
ticular they conclude with a theoretical condition which, in principle, could be 
used to verify manifest declassifiers. Kopf and Basin's study of timing channels 
in synchronous systems [KB06] is the most closely related to the current paper. 
They study a Per model for expressing declassification properties in a timed 
setting - an abstract counterpart to the more programmer-oriented delimited 
release approach used here. They also study verification for deterministic sys- 
tems by the use of reachability in a product automaton - somewhat analogous 
to our use of self composition. Finally their examples include leaks of hamming 
weight in a finite-field exponentiation circuit. 

9 Conclusions and Further Work 

Reusing theoretical concepts and practical verification tools we have introduced 
a notion of side channel declassification and shown how such properties can be 
verified by a combination of simple transformations and application of off-the- 
shelf software model checking tools. We have also introduced a new method to 
specify side-channel declassification, manifest form, a form which makes the secu- 
rity property explicit in the program structure, and makes verification simpler. 
We have applied these techniques to verify the relative security of a number 
of cryptographic algorithms. It remains to investigate how to convert a given 



program into manifest form. Ideas from [MPSW05,LZ05] may be adaptable to 
obtain the best of both worlds: a program without the overhead of manifest 
form, but satisfying the same side-channel declassification property. 
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